Databases and database products are in common use today. A database stores information in objects, such as records, tables, and indexes. In addition to a current version of the information stored in a database, previous versions of the information may be useful to a user.
One way to provide information on previous versions of data is to make a complete copy of the database at a point in time which may be of interest to a user. When this occurs, all files associated with the database are stored. However, this technique is space intensive, because for a database which is stored in a certain amount of storage space, each copy will also require that amount of storage space. This approach may also be time consuming, as the copy itself involves movement of lots of data.
A disk volume snapshot may be provided using a copy-on-write mechanism that stores only a copy of the changed data. Each time a change is made to the original database, the previously stored data is written to the copy of the changed data. However, this volume snapshot is not transactionally consistent. That is, the changes stored may be part of a transaction in progress, and thus the volume snapshot may include partial information regarding a transaction. Special hooks are necessary for applications to use the volume snapshot because of this possible transaction inconsistency. A volume snapshot created in this way may also be structurally inconsistent due to incomplete structural modifications of indices and tables which have been stored. Additionally, in a volume snapshot, the granulatity of the copy is at the volume level. Non-database data may also be copied, which is unnecessary, wasting time and resources.
Versioning of databases has also been provided by making available the data accessed by a particular transaction. Only this data is stored for a given transaction, and thus if data regarding what was accessed by a given transaction is needed, the data accessed (before any changes made by the transaction) may be provided to the user who initiated the transaction. However, this data is not accessible by multiple transactions or users. Where multiple transactions or users attempt to access the same data, the data may be different for these different accesses. Additionally, such versioning is not persistent after a database server restart.
Thus, there is a need for a way to view a database which can be created quickly, is transaction-consistent, provides consistent information to multiple transactions or users, and is persistent after a database server restart.